Skip to content

wgpu-hal: Expose vulkan::PhysicalDeviceFeatures #7682

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 30, 2025

Conversation

afishhh
Copy link
Contributor

@afishhh afishhh commented May 10, 2025

Connections
Fixes #7681

Description
PhysicalDeviceFeatures is currently accessible through vulkan::Adapter::physical_device_features which is a public function. This structure seems required to be able to tell what Vulkan device features wgpu needs so it would be nice if it was accessible externally as otherwise it's impossible to create a wgpu Device from Vulkan objects safely.

Re-exporting the type is the workaround I used just to get what I was doing to succeed, alternatively the whole adapter module could be made public or glob re-exported, this would also expose PhysicalDeviceProperties which appears to have the same issue.

Testing
Call Adapter::physical_device_features, notice that you can't name this type due to it being private.

Squash or Rebase?
Any

Checklist

  • Run cargo fmt.
  • Run taplo format.
  • Run cargo clippy --tests. If applicable, add:
    • --target wasm32-unknown-unknown
  • Run cargo xtask test to run tests.
  • If this contains user-facing changes, add a CHANGELOG.md entry.

@afishhh afishhh requested a review from a team as a code owner May 10, 2025 15:15
@afishhh
Copy link
Contributor Author

afishhh commented May 10, 2025

Ah clippy complains because the documentation links to private items now, not sure what to do about this since the function it links to does indeed seem pretty internal.

@cwfitzgerald cwfitzgerald self-assigned this May 21, 2025
Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should just put an #[expect(...)] on the struct as there's nothing intrinsically wrong with doing what is being done, especially as we build with private items documented on wgpu.rs

downlevel_flags: wgt::DownlevelFlags,
private_caps: PrivateCapabilities,
workarounds: Workarounds,
}

pub use adapter::PhysicalDeviceFeatures;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely shouldn't put the use here - if anything it should be re-exported at the top of the file, near any other re-exports.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved it to be in-line with what the order in wgpu-hal/src/dynamic/mod.rs is (this file didn't have any other re-exports).

@afishhh afishhh force-pushed the public_physical_device_features branch from 9092660 to bef8699 Compare May 30, 2025 14:50
@afishhh afishhh force-pushed the public_physical_device_features branch from bef8699 to 754bb81 Compare May 30, 2025 14:57
@afishhh afishhh requested a review from cwfitzgerald May 30, 2025 15:02
Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@cwfitzgerald cwfitzgerald merged commit a9e04f8 into gfx-rs:trunk May 30, 2025
38 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

wgpu-hal: vulkan::adapter::PhysicalDeviceFeatures is private
2 participants